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Abstract 

Depth-first search is the key to a wide variety of graph al¬ 
gorithms. In this paper we express depth-first search in a 
lazy functional language, obtaining a linear-time implemen¬ 
tation. Unlike traditional imperative presentations, we use 
the structuring methods of functional languages to construct 
algorithms from individual reusable components. This style 
of algorithm construction turns out to be quite amenable to 
formal proof, which we exemplify through a calculational- 
style proof of a far from obvious strongly-connected compo¬ 
nents algorithm. 

1 Introduction 

The importance of depth-first search (DFS) for graph al¬ 
gorithms was established twenty years ago by Tarjan (1972) 
and Hopcroft and Tarjan (1973) in their seminal work. They 
demonstrated how depth-first search could be used to con¬ 
struct a variety of efficient graph algorithms. In practice, 
this is done by embedding code-fragments necessary for a 
particular algorithm into a DFS procedure skeleton in order 
to compute relevant information while the search proceeds. 
While this is quite elegant it has a number of drawbacks. 
Firstly, the DFS code becomes intertwined with the code for 
the particular algorithm, resulting in monolithic programs. 
The code is not built by re-use, and there is no separation 
between logically distinct phases. Secondly, in order to rea¬ 
son about such DFS algorithms we have to reason about a 
dynamic process —what happens and when—and such rea¬ 
soning is complex. 

Occasionally, the depth-first forest is introduced in order 
to provide a static value to aid reasoning. We build on this 
idea. If having an explicit depth-first forest is good for rea¬ 
soning then, so long as the overheads are not unacceptable, 
it is good for programming. In this paper, we present a 
wide variety of DFS algorithms as combinations of standard 
components, passing explicit intermediate values from one 
to the other. The result is quite different from traditional 
presentations of these algorithms, and we obtain a greater 
degree of modularity than is usually seen. 


Of course, the idea of splitting algorithms into many 
separate phases connected by intermediate data structures 
is not new. To some extent it occurs in all programming 
paradigms, and is especially common in functional languages. 
What is new, however, is applying the idea to graph algo¬ 
rithms. The difficulty is always to find a sufficiently flexible 
intermediate value which allows a wide variety of algorithms 
to be expressed in terms of it. 

There is another challenge here, however. Graph algo¬ 
rithms have long been poorly handled in functional lan¬ 
guages. It has not been at all clear how to express such 
algorithms without using side effects to achieve efficiency, 
and lazy languages by their nature have to prohibit side- 
effects. So, for example, many texts provide implementa¬ 
tions of search algorithms which are quadratic in the size of 
the graph (see Paulson (1991), Holyer (1991), or Harrison 
(1993)), compared with the standard linear implementations 
given for imperative languages (see Manber (1989), or Cor- 
man et al. (1990)). 

In our work there is one place where we do need to use 
destructive update in order to gain the same complexity 
(within a constant factor) as imperative graph algorithms. 
We make use of recent advances in lazy functional languages 
which use monads to provide updatable state, as imple¬ 
mented within the Glasgow Haskell compiler. The compiler 
provides extensions to the language Haskell (Hudak et al. 
1992) providing updatable arrays (Launchbury and Peyton 
Jones 1994), and allows these state-based actions to be en¬ 
capsulated so that their external behaviour is purely func¬ 
tional. Consequently we obtain linear algorithms and yet 
retain the ability to perform purely functional reasoning on 
all but one fixed and reusable component. 

Most of the methods in this paper apply equally to strict 
and lazy languages. The exception is in the case when DFS 
is being used for a true search rather than for a complete 
traversal of the graph. In this case, the co-routining be¬ 
haviour of lazy evaluation allows the search to abort early 
without needing to add additional mechanisms like excep¬ 
tions. We give an example of this in Section 6. 

In summary the main contributions of this paper are: 

• We provide implementations of DFS algorithms in lin¬ 
ear time in Haskell. We are careful to provide real code 
throughout, and avoid resorting to pseudo-code. 
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We construct the algorithms using reusable compo¬ 
nents, providing a greater level of modularity than is 
typical in other presentations. 






• We provide examples of correctness proofs. Again, 
these are quite different from traditional proofs, largely 
because they are not based upon reasoning about the 
dynamic process of DFS, but rather about a static 

This paper is organised as follows. Section 2 introduces 
a data type for graphs and some standard functions which 
will be used in subsequent algorithms. Section 3 introduces 
depth-first search. Section 4 describes the Haskell imple¬ 
mentation of several algorithms that use depth-first search 
which includes: topological sorting, strongly connected com¬ 
ponents, as well as others. Section 5 describes the linear 
implementation of depth-first search in Haskell. Section 6 
describes some more complex algorithms that use depth-first 
search, including edge classification and biconnected compo¬ 
nents. Section 7 discusses the complexity of the algorithms. 
Finally, Section 8 discusses related work. 

2 Representing graphs 

In order to meet our goal of not resorting to pseudo-code, 
we need to begin with some boring details. There are many 
ways to represent (directed) graphs. For our purposes, we 
use an array of adjacency lists. The array is indexed by 
vertices, and each component of the array is a list of those 
vertices reachable along a single edge. This adjacency struc¬ 
ture is linear in the size of the graph, that is, the sum of 
the number of vertices and the number of edges. By us¬ 
ing an indexed structure we are able to be explicit about 
the sharing that occurs in the graph. Another alternative 
would have been to use a recursive tree structure and rely 
on cycles within the heap. However, the sharing of nodes in 
the graph would then be implicit making a number of tasks 
harder. 

So we will just use a standard Haskell immutable array. 
This gives constant time access (but not update—these ar¬ 
rays may be shared arbitrarily). 

We can use the same mechanism to represent undirected 
graphs as well, simply by ensuring that we have edges in 
both directions. An undirected graph is a symmetric di¬ 
rected graph. We could also represent multi-edged graphs 
by a simple extension, but will not consider them here. 

Graphs, therefore, may be thought of as a table indexed 
by vertices. 

type Table a = Array Vertex a 
type Graph = Table [Vertex] 

The type Vertex may be any type belonging to the Haskell 
index class lx, which includes Int, Char, tuples of indices, 
and more. Haskell arrays come with indexing (!) and the 
functions indices (returning a list of the indices) and bounds 
(returning a pair of the least and greatest indices). We pro¬ 
vide vertices as an alternative for indices, which returns 
a list of all the vertices in a graph, 
vertices :: Graph -> [Vertex] 
vertices = indices 

Sometimes it is convenient to extract a list of edges from 
the graph, this is done with the function edges. An edge is 
a pair of vertices, 
type Edge = (Vertex,Vertex) 

edges :: Graph -> [Edge] 
edges g = [ (v,w) I v <- vertices g, w < 


To manipulate tables (including graphs) we provide a generic 
function mapT which applies its function argument to every 
table index/entry pair, and builds a new table. 

mapT :: (Vertex -> a -> b) -> Table a -> Table b 
mapT f t = array (bounds t) 

[(v, f v (t!v)) | vC-indices t] 

The Haskell function array takes low and high bounds and 
a list of index/value pairs 1 , and builds the corresponding 
array in linear time. Because we are using an array-based 
implementation we often need to provide a pair of vertices 
as array bounds. So for convenience we define, 

type Bounds = (Vertex,Vertex) 

Using mapT we could define, 

outdegree :: Graph -> Table Int 
outdegree g = mapT numEdges g 

where numEdges v ws = length ws 

which builds a table detailing the number of edges leaving 
each vertex. 

To build up a graph from a list of edges we define buildG. 

buildG :: Bounds -> [Edge] -> Graph 

buildG bnds es = accumArray (flip (:)) [] bnds es 

Like array the Haskell function accumArray builds an ar¬ 
ray from a list of index/value pairs, with the difference that 
accumArray accepts possibly many values for each indexed 
location, which are combined using the function provided as 
accumArray’s first argument. Here we simply build lists of 
all the values associated with each index. Again, construct¬ 
ing the array takes linear time with respect to the length of 
the adjacency list. So in linear time, we can convert a graph 
defined in terms of edges to the vertex table based graph. 
For example, 

graph = buildG (’a’,’j’) 

[(’a’,’j’),(’a’,’g’),(’b’,’i’), 

(’b’,’a’),(’c’,’h’),(’c’,’e’), 

(’e’,’j’),(’e’,’h’),(’e’,’d’), 

(’f ’ , ’ i ’) , (’g’ , ’f ’) , (’g’ , ’b’)] 

will produce the array representation for the graph shown 
in Figure 1. 

Then, to find the immediate successors to ’ e ’, say, we 
graph ! ’e’ 

which returns [ ’ d ’ , ’h’, ’ j ’ ] . 

Combining the functions edges and buildG gives us a 
way to reverse all the edges in a graph giving the transpose 
of the graph: 

transposeG :: Graph -> Graph 

transposeG g = buildG (bounds g) (reverseE g) 

reverseE :: Graph -> [Edge] 

reverseE g = [ (w,v) I (v,w) <- edges g] 

We extract the edges from the original graph, reverse their 
direction, and rebuild a graph with the new edges. Then, 
for example, 


g! v] 
















Figure 1: A directed graph. 


(transposeG graph) ! ’e’ 

will return [’c’]. Now by using transposeG we can imme¬ 
diately define an indegree table for vertices: 

indegree :: Graph -> Table Int 
indegree g = outdegree (transposeG g) 

This example gives a first feel for the approach we advocate 
in this paper. Rather than defining indegree from scratch 
by, for example, building an array incrementally as we tra¬ 
verse the graph, we simply reuse previously defined func¬ 
tions, combining them in a fresh way. The result is shorter 
and clearer, though potentially more expensive (an inter¬ 
mediate array is constructed). There are two things to say 
about this additional cost. Firstly, the additional cost only 
introduces a constant factor into the complexity measure, so 
the essence of the algorithm is preserved. Secondly, recent 
work in the automatic removal of intermediate structures 
(deforestation) comes a long way to removing this problem. 

3 Depth-first search 

The traditional view of depth-first search is as a process 
which may loosely be described as follows. Initially, all the 
vertices of the graph are deemed “unvisited”, so we choose 
one and explore an edge leading to a new vertex. Now we 
start at this vertex and explore an edge leading to another 
new vertex. We continue in this fashion until we reach a 
vertex which has no edges leading to unvisited vertices. At 
this point we backtrack, and continue from the latest vertex 
which does lead to new unvisited vertices. 

Eventually we will reach a point where every ygrfegx reach¬ 
able from the initial vertex has been visited. If there are any 
unvisited vertices left, we choose one and begin the search 
again, until finally every vertex has been visited once, and 
every edge has been examined. 

In this paper we will concentrate on depth first search 
as a specification for a value, namely the spanning forest 
defined by a depth-first traversal of a graph. Such a for¬ 
est for the graph in Figure 1 is depicted in Figure 2. The 
(solid) tree edges are those graph edges which lead to un¬ 
visited vertices. The remaining graph edges are also shown, 
but in dashed lines. These edges are classified according 
to their relationship with the tree, namely, forward edges 
(which connect ancestors in the tree to descendants), back 
edges (the reverse), and cross edges (which connect nodes 
across the forest, but always from right to left). This stan¬ 
dard classification is useful for thinking about a number of 


algorithms and later, in Section 6, we give an algorithm for 
classifying edges in this way. 

3.1 Specification of depth-first search 

As the approach to DFS algorithms which we explore in 
this paper is to manipulate the depth-first forest explicitly, 
the first step, therefore, is to construct the depth-first forest 
from a graph. To do this we need an appropriate definition 
of trees and forests. 

A forest is a list of trees, and a tree is a node containing 
some value, together with a forest of sub-trees. Both trees 
and forests are polymorphic in the type of data they may 
contain. 

data Tree a = Node a (Forest a) 
type Forest a = [Tree a] 

A depth-first search of a graph takes a graph and an initial 
ordering of vertices. All graph vertices in the initial ordering 
will be in the returned forest. 

dfs :: Graph -> [Vertex] -> Forest Vertex 

This function is the pivot of this paper. For now we re¬ 
strict ourselves to considering its properties, and will leave 
its Haskell implementation until Section 5. 

Sometimes the initial ordering of vertices is not impor¬ 
tant. When this is the case we use the related function 

dff :: Graph -> Forest Vertex 
dff g = dfs g (vertices g) 

What are the properties of depth-first forests? They can be 
completely characterised by the following two conditions. 

(i) The depth-first forest of a graph is a spanning sub¬ 
graph, that is, it has the same vertex set, but the edge 
set is a subset of the graph edge set. 

(ii) The graph contains no left-right cross-edges with re¬ 
spect to the forest. 

Later on in the paper, we find it convenient to talk in 
terms of paths rather than single edges: a path being made 
up of zero or more edges joined end to end. We will write 
v —>g w to mean that there is a path from v to w in the 
graph g. Where there will be no confusion we will drop the 
graph subscript. 

The ban on left-right cross edges translates into paths. 
At the top level, it implies that there is no path from any 





vertex in one tree to any vertex in a tree that occurs later 
in the forest. Thus 2 , 

Property 1 

If (ts++us=dff g), then Vr £ ts . Vro £ us . v -f-> w □ 

Deeper within each tree of the forest, there can be paths 
which traverse a tree from left to right, but the absence of 
any graph paths which cross the tree structure from left to 
right implies that the path has to follow the tree structure. 
That is: 

Property 2 

If the tree (Node x (ts++us)) is a subtree occurring any¬ 
where within dff g, then 

Vr £ ts . Ww £ us . v —> w => v —> x 

□ 

So the only way to get from v to w is via (an ancestor of) 
x, the point at which the forests that contain v and w are 
combined (otherwise there would be a left-right cross edge). 
Thus there is also a path from v to x. 

The last property we pick out focusses on dfs, and pro¬ 
vides a relationship between the initial order, and the struc¬ 
ture of the forest 3 . 

Property 3 

Let a and b be any two vertices. Write —y for paths in 
the graph g, and < for the ordering induced by the list of 
vertices vs. Then 

3t £ dfs g vs. a £ t A b £ t 

^ (Vd _ d —>■ a VW —>■ b =>• c < d) 

□ 

This Property says that: 

(=>) given two vertices that occur within a single depth-first 
tree (taken from the forest), then there is a predecessor 
of both (with respect to —>) which occurs earlier in 
vs than any other predecessor of either. (If this were 
not the case, then a and b would end up in different 
trees). 

(•$=) if the earliest predecessor of either a or b is a prede¬ 
cessor of them both, then they will end up in the same 
tree (rooted by this predecessor). 

These three properties are certainly true of DFS span¬ 
ning forests, but we make no claim about their completeness. 
There are other useful properties not derivable from these. 


z We use the notation ts++us to indicate any division of the list of 
trees in the forest, such that the order of the trees is preserved. Note 
that either ts or us could be empty. Also, we use E to indicate forest 



4 Depth-first search algorithms 
Algorithm 1. Depth-first search numbering 

Having specified DFS (at least partly) we turn to consider 
how it may be used. The first algorithm is straightforward. 
We wish to assign to each vertex a number which indicates 
where that vertex came in the search. A number of other 
algorithms make use of this depth-first search number, in¬ 
cluding the biconnected components algorithm that appears 
later, for example. 

We can express depth-first ordering of a graph g most 
simply by flattening the depth-first forest in preorder. Pre¬ 
order on trees and forests places ancestors before descen¬ 
dants and left subtrees before right subtrees 4 : 

preorder :: Tree a -> [a] 

preorder (Node a ts) = [a] ++ preorderF ts 

preorderF :: Forest a -> [a] 
preorderF ts = concat (map preorder ts) 

Now obtaining a list of vertices in depth-first order is easy: 

preOrd :: Graph -> [Vertex] 
preOrd g = preorderF (dff g) 

However, it is often convenient to translate such an ordered 
list into actual numbers. For this we could use the function 
tabulate: 

tabulate :: Bounds -> [Vertex] -> Table Int 
tabulate bnds vs = array bnds (zip vs [1..]) 

which zips the vertices together with the positive integers 
1, 2, 3,..., and (in linear time) builds an array of these 
numbers, indexed by the vertices. 

We can package these up into a function as follows: 

preArr :: Bounds -> Forest Vertex -> Table Int 
preArr bnds ts = tabulate bnds (preorderF ts) 

(it turns out to be convenient for later algorithms if such 
functions take the depth-first forest as an argument, rather 
than construct the forest themselves.) 

Algorithm 2. Topological sorting 

The dual to preorder is postorder, and unsurprisingly this 
turns out to be useful in its own right. Postorder places 
descendants before ancestors and left subtrees before right 

postorder :: Tree a -> [a] 

postorder (Node a ts) = postorderF ts ++ [a] 


postorderF :: Forest a -> [a] 
postorderF ts = concat (map postorder ts) 

So, like with preorder, we define, 


postOrd :: Graph -> [Vertex] 
postOrd g = postorderF (dff g) 








The lack of left-right cross edges in DFS forests leads to 
a pleasant property when a DFS forest is flattened in pos¬ 
torder. To express this we need a definition. 

Definition 

A linear ordering < on vertices is a post-ordering with re¬ 
spect to a graph g exactly when, 

□ 

(where v <—> u means v —> u and u —> v). In words, this 
definition states that, if from some vertex v there is a path 
to a vertex later in the ordering, then there is also a vertex 
u which occurs no earlier than w and which, like w is also 
reachable by a path from v. In addition, however, there is 
also a path from » to ». 

This property is so-named because post order flattening 
of depth first forests have this property. 

Theorem 4 

If vs=postOrd g, then the order in which the vertices appear 
in vs is a post-ordering with respect to g. 

Proof 

If v comes before w in a post order flattening of a forest, 
then either w is an ancestor of v, or w is to the right of v 
in the forest. In the first case, take w as u. For the second, 
note that as v —> w, by Property 1, v and w cannot be in 
different trees of the forest. Then by Property 2, the lowest 
common ancestor of v and w will do. □ 

We can apply all this to topological sorting. A topologi¬ 
cal sort is an arrangement of the vertices of a directed acyclic 
graph into a linear sequence vi , . . . , v n such that there are 
no edges from vj to v t where i < j. This problem arises 
quite frequently, where a set of tasks need to be scheduled, 
such that every task can only be performed after the tasks 
it depends on are performed. 

We define, 

topSort :: Graph -> [Vertex] 
topSort g = reverse (postOrd g) 

Why is this correct? If w comes before v in the result of 
topSort g, then v comes before w in the result of postOrd g. 
Thus, by Theorem 4, there exists a vertex u no earlier than 
w which is in a cycle with v. But, by assumption, the graph 
is acyclic, so no such path v —> w exists. 

Algorithm 3. Connected components 

Two vertices in an undirected graph are connected if there 
is a path from the one to the other. In a directed graph, 
two vertices are connected if they would be connected in 
the graph made by viewing each edge as undirected. Fi¬ 
nally, with an undirected graph, each tree in the depth-first 
spanning forest will contain exactly those vertices which con¬ 
stitute a single component. 

We can translate this directly into a program. The func¬ 
tion components takes a graph and produces a forest, where 
each tree represents a connected component. 

components :: Graph -> Forest Vertex 
components g = dff (undirected g) 

where a graph is made undirected by: 


undirected :: Graph -> Graph 
undirected g = buildG (bounds g) 

(edges g ++ reverseE g) 

The undirected graph we actually search may have dupli¬ 
cate edges, but this has no effect on the structure of the 
components. 

Algorithm 4. Strongly connected components 

Two vertices in a directed graph are said to be strongly con¬ 
nected if each is reachable from the other. A strongly con¬ 
nected component is a maximal subgraph, where all the ver¬ 
tices are strongly connected with each other. This problem 
is well known to compiler writers as the dependency analysis 
problem—separating procedures/functions into mutually re¬ 
cursive groups. We implement the double depth-first search 
algorithm of Kosaraju (unpublished), and Sharir (1981). 

see :: Graph -> Forest Vertex 

see g = dfs (transposeG g) (reverse (postOrd g)) 

The vertices of a graph are ordered using postOrd. The 
reverse of this ordering is used as the initial vertex order 
for a depth-first traversal on the transpose of the graph. 
The result is a forest, where each tree constitutes a single 
strongly connected component. 

The algorithm is simply stated, but its correctness is not 
at all obvious. However, it may be proved as follows. 

Theorem 5 

Let a and b be any two vertices of g. Then 

(ate see g. aetAbet) & a^b 

Proof 

The proof proceeds by calculation. We write g T for the 
transpose of g. Paths —>■ in g will be paths i — in g T . 
Further, let < be the post-ordering defined by postOrd g. 
Then its reversal induces the ordering >. Now, 

at e see g . a e t a b e t 

•O- { Definition of see } 

at G df s g T (reverse (postOrd g)) . a, b £ t 
{ By Property 3 } 

3c . c <— a A cm— b A 
(Vd . d i — a V d i — b =>• c > d) 

3c . a —y c A b —y c A 
(Vd . a —> d V b —> d =>• d < c) 

From here on we construct a loop of implications. 

3 c . a —► c A b —► c A 
(Vd . a —► d V b —► d =* d < c) 

=> { Consider d = a and d = b } 

3c . a —y c A a < c A b^ c A b < c A 
(Vd . a —> d V b ^d => d<c) 

=>■ { < is a post-ordering } 

3c . (3e . a ^ e A c < e)A 
(3/ • b i >■ / A c < /) A 
(Vd . a —y d V b —y d =A d < c) 

=> { e = c and / = c using (Vd. . .) } 

3c . a i—y c A b i—y c 
=> { Transitivity } 







which gives us one direction. But to complete the loop: 

=> { There is a latest vertex reachable from a or b } 

a * ^ b A 3c . (a y c V b y c) A 
(Vd . a d V b —► d =* d < c) 

=>■ { Transitivity of —y } 

3c . a —y c A b —y c A 

(Vd . a —y d V b —y d =>• d < c) 

as required, and so the theorem is proved. □ 

To the best of our knowledge, this is the first calcula- 
tional proof of this algorithm. Traditional proofs (see Cor- 
man et al. (1990), for example) typically take many pages 
of wordy argument. In contrast, because we are reusing an 
earlier algorithm, we are able to reuse its properties also, 
and so obtain a compact proof. Similarly, we believe that it 
is because we are using the DFS forest as the basis of our 
program that our proofs are simplified as they are proofs 
about values rather than about processes. 

A minor variation on this algorithm is to reverse the roles 
of the original and transposed graphs: 

see’ :: Graph -> Forest Vertex 

sec’ g = dfs g (reverse (postOrd (transposeG g))) 

The advantage now is that not only does the result ex¬ 
press the strongly connected components, but it is also a 
valid depth-first forest for the original graph (rather than 
for the transposed graph). This alternative works as the 
strongly connected components in a graph are the same as 
the strongly connected components in the transpose of the 
graph. 

5 Implementing depth-first search 

In order to translate a graph into a depth-first spanning 
tree we make use of a technique common in lazy functional 
programming: generate then prune. Given a graph and a 
list of vertices (a root set), we first generate a (potentially 
infinite) forest consisting of all the vertices and edges in the 
graph, and then prune this forest in order to remove repeats. 
The choice of pruning pattern determines whether the forest 
ends up being depth-first (traverse in a left-most, top-most 
fashion) or breadth-first (top-most, left-most), or perhaps 
some combination of the two. 

5.1 Generating 

We define a function generate which, given a graph g and a 
vertex v builds a tree rooted at v containing all the vertices 
in g reachable from v. 

generate :: Graph -> Vertex -> Tree Vertex 
generate g v = Node v (map (generate g) (g!v)) 

Unless g happens to be a tree anyway, the generated tree 
will contain repeated subtrees. Further, if g is cyclic, the 
generated tree will be infinite (though rational). 

Of course, as the tree is generated on demand, only a 
finite portion will be generated. The parts that prune dis¬ 
cards will never be constructed. 


5.2 Pruning 

The goal of pruning the (infinite) forest is to discard sub¬ 
trees whose roots have occurred previously. Thus we need to 
maintain a set of vertices (traditionally called “marks”) of 
those vertices to be discarded. The set-operations we require 
are initialisation (the empty set), membership test, and ad¬ 
dition of a singleton. While we are prepared to spend linear 
time in generating the empty set (as it is only done once), 
it is essential that the other operations may be performed 
in constant time. 

The easiest way to achieve this is to make use of state 
transformers, and mimic the imperative technique of main¬ 
taining an array of booleans, indexed by the set elements. 
This is what we do. We provide an explanation of state- 
transformers in the Appendix, but as they have already 
been described in a number of papers (Moggi 1989, Wadler 
1990, Peyton Jones and Wadler 1993, Launchbury 1993, 
Launchbury and Peyton Jones 1994), and already been im¬ 
plemented in more than one Haskell variant, we avoid clut¬ 
tering the main text. 

The implementation of vertex sets is easy: 
type Set s = MutArr s Vertex Bool 

mkEmpty :: Bounds -> ST s (Set s) 
mkEmpty bnds = newArr bnds False 

contains :: Set s -> Vertex -> ST s Bool 
contains m v = readArr m v 

include :: Set s -> Vertex -> ST s () 
include m v = writeArr m v True 

Using these, we define prune as follows. 

prune :: Bounds -> Forest Vertex -> Forest Vertex 
prune bnds ts 

= runST (mkEmpty bnds ‘thenST‘ \m -> 

The prune function begins by introducing a fresh state thread, 
then generates an empty set within that thread and calls 
chop. The final result of prune is the value generated by 
chop, the final state being discarded. 


chop::Set s -> Forest Vertex-> ST s (Forest Vertex) 
chop m [] = returnST [] 
chop m (Node v ts : us) 

= contains m v ‘thenST‘ \visited -> 
if visited then 
chop m us 
else 

include m v ‘thenST‘ \_ -> 

chop m ts ‘thenST‘ \as -> 

chop m us ‘thenST' \bs -> 

returnST ((Node v as) : bs) 

When chopping a list of trees, the root of the first is exam¬ 
ined. If it has occurred before, the whole tree is discarded. 
If not, the vertex is added to the set represented by m, and 
two further calls to chop are made in sequence. 

The first, namely, chop m ts, prunes the forest of de¬ 
scendants of v, adding all these to the set of marked ver¬ 
tices. Once this is complete, the pruned subforest is named 
as, and the remainder of the original forest is chopped. The 
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result of this is, in turn, named bs, and the resulting forest 
is constructed from the two. 

All this is done lazily, on demand. The state combina- 
tors force the computation to follow a predetermined linear 
sequence, but exactly where in that sequence the compu¬ 
tation is, is determined by external demand. Thus if only 
the top-most left-most vertex were demanded then that is 
all that would be produced. On the other hand, if only the 
final tree of the forest is demanded, then because the set 
of marks is single-threaded, all the previous trees will be 
produced. However, this is demanded by the very nature 
of DFS anyway, so it is not as restrictive as it may at first 

At this point one may wonder whether any benefit has 
been gained by using a functional language. After all, the 
code looks fairly imperative. To some extent such a com¬ 
ment would be justified, but it is important to note that 
this is the only place in the development that destructive 
operations have to be used to gain efficiency. We have the 
flexibility to gain the best of both worlds: where destruc¬ 
tive update is vital we use it, where it is not vital we use 
the powerful modularity options provided by lazy functional 
languages. 

5.3 DFS 

The components of generate and prune are combined to pro¬ 
vide the definition of DFS. 


The above diagram expresses the relationship between 
the four types of edge (tree edges (T), forward edges (F), 
back edges (B), and cross edges (C)) and the preorder and 
postorder numbers. Only back edges go from lower pos¬ 
torder numbers to higher, whereas only cross edges go from 
higher to lower in both orderings. Forward edges, which are 
the composition of tree edges, cannot be distinguished from 
tree edges by this means—both tree edges and forward edges 
go from lower preorder numbers to higher (and conversely 
in postorder)—but as we can already determine which are 
tree edges there is no problem. The implementation of these 
principles is now immediate and presented in Figure 3. 

To classify an edge we generate the depth-first spanning 
forest, and use this to produce preorder and postorder num¬ 
bers. We then have all the information required to construct 
the appropriate subgraph. 

Algorithm 6. Finding reachable vertices 

Finding all the vertices that are reachable from a single ver¬ 
tex v demonstrates that the df s doesn’t have to take all the 
vertices as its second argument. Commencing a search at v 
will construct a tree containing all of v’s reachable vertices. 
We then flatten this with preorder to produce the desired 
list. 

reachable :: Graph -> Vertex -> [Vertex] 
reachable g v = preorderF (dfs g [v]) 


dfs g vs = prune (bounds g) (map (generate g) vs) 

The argument vs is a list of vertices, so the generate func¬ 
tion is mapped across this (having been given the graph g). 
The resulting forest is pruned in a left-most top-most fashion 
by prune. 

If paying an extra logarithmic factor is acceptable, then 
it is possible to dispense completely with the imperative 
features used in prune, and to use an implementation of 
sets based upon balanced trees, for example. 

6 More algorithms 
Algorithm 5. Classifying edges 

We have already seen the value of classifying the graph edges 
with respect to a given depth-first search. Here we codify 
the idea by building subgraphs of the original containing all 
the same vertices, but only a particular kind of edge. 

Tree edges are easiest, these are just the edges that ap¬ 
pear explicitly in the spanning forest. The other edges may 
be distinguished by comparing preorder and/or postorder 
numbers of the vertices of an edge. We can summarise the 
situation in the following diagram: 



One application of this algorithm is to test for the existence 
of a path between two vertices: 

path :: Graph -> Vertex -> Vertex -> Bool 
path g v w = w ‘elem‘ (reachable g v) 

The elem test is lazy: it returns True as soon as a match 
is found. Thus the result of reachable is demanded lazily, 
and so only produced lazily. As soon as the required ver¬ 
tex is found the generation of the DFS forest ceases. Thus 
dfs implements a true search and not merely a complete 
traversal. 

Algorithm 7. Biconnected components 

We end by programming a more complex algorithm—finding 
biconnected components. An undirected graph is biconnected 
if the removal of any vertex leaves the remaining subgraph 
connected. This has a bearing in the problem of reliabilitym. 
communication networks. For example, if you want to avoid 
driving through a particular town, is there an alternative 

If a graph is not biconnected the vertices whose removal 
disconnects the graph are known as articulation points. Lo¬ 
cating articulation points allows a graph to be partitioned 
into biconnected components (actually a partition of the 
edges). In Figure 4 vertices that are articulation points are 
marked with an asterisk. The naive, brute force method 
requires 0(V(V + E)) time (where the problem graph has 
V vertices and E edges). A more efficient algorithm is de¬ 
scribed by Tarjan (1972), where biconnected components are 
found during the course of a depth-first search in 0(V + E) 
time. Here we apply the same theory as Tarjan, but express 
it via explicit intermediate values. 

Tarjan’s method is based on the following theorem: 












tree :: Bounds -> Forest Vertex -> Graph 
tree bnds ts = buildG bnds (concat (map flat ts)) 
where 

flat (Node v ts) = [ (v,w) I Node w us <- ts] ++ concat (map flat ts) 

back :: Graph -> Table Int -> Graph 
back g post = mapT select g 

where select v ws = [ w I w <- ws, post!v<post!w ] 

cross :: Graph -> Table Int -> Table Int -> Graph 
cross g pre post = mapT select g 

where select v ws = [ w I w <- ws, post!v>post!w, pre!v>pre!w] 

forward :: Graph -> Graph -> Table Int -> Graph 
forward g tree pre = mapT select g 

where select v ws = [ w I w <- ws, pre!v<pre!w] \\ treelv 


Figure 3: Classification of graph edges. 



/- a 

Figure 4: An undirected graph. 

Theorem 6 

Given a depth-first spanning forest of a graph, v is an ar¬ 
ticulation point in the graph if and only if: (i) v is a root 
with more than one child; or (ii) v is not a root, and for all 
proper descendants w of v there are no edges to any proper 
ancestors of v. 

We apply this theorem by associating a low point number 
with every vertex. The low point number of v is the smallest 
DFS numbered vertex that can be reached by following zero 
or more tree edges, and then along a single graph edge. 

We calculate low point numbers by traversing the DFS 
trees bottom-up, and associating each vertex with its low 
point number. The function label (see Figure 6) annotates 
a tree with both depth-first numbers and low-point numbers. 
At any vertex, the low point number is the minimum of: 

(i) the DFS number of the vertex; 

(ii) the DFS numbers of the vertices reached by a single 
edge; and 

(iii) the low point numbers of the vertex’s descendants in 
the tree. 

For example, the result of running label on the DFS 
spanning tree produced from the graph in Figure 4, gives 
the annotated tree depicted in Figure 5. 


Figure 5: The depth-first forest for the undirected graph. 


Dashed lines are the important back edges used for cal¬ 
culating low points. Tree nodes are triples, for instance, 
e (5,J), represents the triple (e, 5, 1 ), where 5 is the depth- 
first number and 1 the low point number of vertex e. 

Now that we have low points for vertices we can calculate 
articulation points. By part (ii) of Theorem 6 if the depth- 
first number of v is less than or equal to the low point of w 
then v is an articulation point. 

The function collect coalesces each DFS tree into a bi- 
connected tree, that is, a tree where the node elements are 
biconnected components. At each node the DFS number is 
compared with the low-point number of all the children. If 
the child’s low-point number is strictly less than the node’s 
DFS number, then the component involving that vertex is 
not completed. On the other hand, if the node’s DFS num¬ 
ber is less than or equal to the child’s low-point number, 
then that component is completed once the node is included. 
The function bicomps handles the special case of the root. 
Finally, bcc ties all the other functions together. 

Coalescing the tree from Figure 5 will produce the fol¬ 
lowing forest containing two trees. 

While this algorithm is complex, again it is made up of 
individual components whose correctness may (potentially 
at least) be established independently of the other compo¬ 
nents. This is quite unlike typical imperative presentations 
where the bones of the recursive DFS procedure are filled 
out with the other components of the algorithm, resulting 
in a single monolithic procedure. 




bcc :: Graph -> Forest [Vertex] 

bcc g = (concat . map bicomps . map (label g dnum)) forest 
where forest = dff g 

dnum = preArr (bounds g) forest 

label :: Graph -> Table Int -> Tree Vertex -> Tree (Vertex,Int,Int) 
label g dnum (Node v ts) = Node (v,dnum!v,lv) us 
where us = map (label g dnum) ts 

lv = minimum ([dnum!v]++[ dnumlw I w <- g!v] 

++[ lu | Node (u,dw,lu) xs <- us]) 

bicomps :: Tree (Vertex,Int,Int) -> Forest [Vertex] 
bicomps (Node (v,dv,lv) ts) 

= [ Node (v:vs) us I (1, Node vs us) <- map collect ts] 

collect :: Tree (Vertex,Int,Int) -> (Int, Tree [Vertex]) 
collect (Node (v,dv,lv) ts) = (lv, Node (v:vs) cs) 
where collected = map collect ts 

vs = concat [ ws I (lw, Node ws us) <- collected, lw<dv] 
cs = concat [ if lw<dv then us else [Node (v:ws) us] 

I (lw, Node ws us) <- collected] 


Figure 6: Biconnected components algorithm. 


[a,b] [a,e,h,i\ 

/ \ 

[b,d,c\ [e,f,g] 


Figure 7: The biconnected trees. 


7 Analysis of depth-first search 
7.1 Complexity 

Models for complexity analysis of imperative languages have 
been established for many years, and verified with respect to 
reality across many implementations. Using these models it 
is possible to show that traditional implementations of the 
various DFS algorithms are linear in the size of the graph 
(that is, run in 0(V + E) time). 

Corresponding models for lazy functional languages have 
not been developed to the same level, and where they have 
been developed there has not yet been the same extensive 
verification. Using these models, (see for example Sands 
(1993)) we believe our implementation of the DFS algo¬ 
rithms to be linear, but because these models have not been 
fully tested, we also ran empirical tests ourselves. 

We took measurements on the strongly connected com¬ 
ponents algorithm, which uses two depth-first searches. The 
results of our experiment are in Figure 8. Timings were 
taken on randomly generated graphs (with differing numbers 
of vertices and edges) and are accurate to approximately 1%. 

The results are quite clear. The plotted points clearly all 
lie on a plane, indicating the linearity of the algorithm. 

We were also curious as to the constant factor that we 
are paying over an imperative language. We coded up Tar- 
jan’s biconnected components algorithm in C, and compared 
with our Haskell implementation. For the graphs we tested 
Haskell was between 10 and 20 times slower than C. This 



Figure 8: Measurements taken on the strongly connected 
components algorithm. 


was better than we expected as the Haskell implementation 
is multi-pass whereas the C implementation was the mono¬ 
lithic single-pass algorithm. 

8 Related work 

Kashiwagi and Wise (1991) also express their graph algo¬ 
rithms in Haskell. They express a graph problem in terms 
of a set of recursive equations, and the algorithm is the fixed 
point of these equations. The graphs are represented by 
lists, so the algorithms have poor complexity, but are suit¬ 
able for parallel evaluation. Unfortunately, many of their 
algorithm implementations are long and unreadable, giving 
little insight into the structure of the problem. For example, 
their strongly connected components algorithm is a page of 
intricate Haskell. 
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Barth et al. (1991) describe M-structures in the paral¬ 
lel functional language Id which are well suited for state 
based computation. For instance, an M-structure array can 
be used for holding marks to express whether a vertex has 
been visited before or not during a traversal. The strength 
of M-structures is that they are designed to support parallel 
evaluation: their drawback is that referential transparency 
is lost. With regard to depth-first search, Reif (1985) gives 
strong evidence that it is inherently sequential; its computa¬ 
tional complexity cannot be improved upon by parallel com¬ 
putation. So while M-structures provide a valuable method 
for general graph searching in parallel, they provide little 
help for the particular case of depth-first search. 

The Graph Exploration Language (GEL) of Erwig (1992) 
provides explicit extensions to a lazy functional language. 
These are exploration operators, which give a concise way of 
expressing many graph algorithms. However, not all graph 
problems can be expressed in terms of a given set of prede¬ 
fined high-level operations, and it seems less than ideal to 
add new language concepts for every new class of problem 
that is tackled. 

Burton and Yang (1990) experimented with multi-linked 
structures. They use arrays which are implemented using 
balanced trees to represent heaps. They give many exam¬ 
ples of using multi-linked structures using heaps, one exam¬ 
ple is an arbitrary depth-first search function. A drawback 
with their approach is that heaps have to be passed to and 
returned from each function. Another is that, by using bal¬ 
anced trees a logarithmic factor is incurred, so their depth- 
first search function is not linear in the size of the graph. 
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Appendix 


Imperative features were initially introduced into the Glas¬ 
gow Haskell compiler to perform input and output, see Pey¬ 
ton Jones and Wadler (1993). The approach is based on 
monads (Moggi 1989, Wadler 1990), and can easily be ex¬ 
tended to achieve in-situ array updates. Launchbury (1993) 
showed how the original model could be extended to allow 
the imperative actions to be delayed until their results are 
required. This is the model we use. 

We will use the monad of state-transformers with type 
constructor ST which is defined: 

type ST s a = s -> (a,s) 

So elements of type ST s Int, say, are functions which, 
when applied to the state, return a pair of an integer to¬ 
gether with a new state. As usual we have the unit returnST 
and the sequencing combinator thenST: 

returnST :: a -> ST s a 
returnST a s = (a,s) 

thenST :: ST s a -> (a -> ST s b) -> ST s b 
(m ‘thenST‘ k) s = k a t where (a,t) = m s 

The ST monad provides three basic array operations: 

newArr ::lx i=> (i,i) -> a ->ST s (MutArr s i a) 

readArr ::lx i=> MutArr s i a -> i -> ST s a 

writeArr::lx i=> MutArr s i a -> i -> a ->ST s () 

The first, newArr, takes a pair of index bounds (the type a 
must lie in the index class lx) together with an initial value, 
and returns a reference to an initialised array. The time 
this operation takes is linear with respect to the number of 
elements in the array. The other two provide for reading and 
writing to an element of the array, and both take constant 

Finally, the ST monad comes equipped with a function 

runST. 

runST :: (Vs . ST s a) -> a 

This takes a state-transformer function, applies it to an ini¬ 
tial state, extracts the final value and discards the final 
state. The type of runST is not Hindley-Milner because of 
the nested quantifier, so it must be built-in to Haskell. The 
universal quantifier ensures that in a state thread variables 
from other state threads are not referenced. For details of 
this see Launchbury and Peyton Jones (1994). 

So, for example, 

runST (newArr (1,8) 0 ‘thenST' (\nums -> 

writeArr nums 5 42 ‘thenST' (\_ -> 
readArr nums 5 'thenST' (\v -> 

returnST v)))) 

will return 42. This can be read as follows: run a new state 
thread extracting the final value when finished; create a new 
array indexed from 1 to 8 with components all 0; then bind 
this array to nums; write to array nums at index 5 the value 
42; then read the component in nums at index 5 and bind 
this value to v; finally return value v. Note that the final 
expression returnST v is unnecessary as readArr returns a 
value. The parentheses immediately after ‘thenST' are also 
unnecessary, as Haskell’s grammar binds lambda expressions 
tighter than infix functions. 
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